NOVA - For the NeXT Workstation

home *** CD-ROM | disk | FTP | other *** search

/ NOVA - For the NeXT Workstation / NOVA - For the NeXT Workstation.iso / Newsletters / GEnieUnixNews / unxnl-03.92 < prev next >

Wrap

Text File | 1992-12-27 | 26KB | 572 lines

_ _ _ _ _ _ // // //| // // \// N E W S //_// // |// // /\\ Vol 3, Issue 3 - March 1992 R o u n d T a b l e (tm) Items of interest to participants of the GEnie Unix RoundTable The RoundTable SysOps are: Andy Finkenstadt....ANDY Rick Mobley.........LRARK Gary Smith..........GARS Brian Riley.........DELPHI All Unix SysOps.....UNIXSYSOPS$ We strongly encourage you to contact any or all of us if you have -ANY- comments or suggestions. This is -YOUR- RoundTable. We are here to make your participation as pleasant and beneficial as possible. ED: editor notes - Thanks -- Sometimes in the rush of things we forget to look around and see how things are going. Obviously, the architects of Unix thought this might be a reasonable plan when they gave us tools like fsk(). It is a fact, good or bad, that Rick (LRARK) and I are the only SysOps remaining from the original group that shepherded the Unix RoundTable into existance in mid-1989. Quite frankly, we didn't know what kind of future we had with GEnie. The SysOp crew is not the only thing that has changed. The user base has grown, and much to our delight it has retained the mix of novice, curious onlooker and seasoned wizzard we witnessed in our beginnings. What has changed dramatically is the depth of information available in both the Bulletin Board and Library areas. The credit for this belongs to loyal and sharing participants. That's you! Whoever you are, if you are reading this editorial, you are party to the success you are benefitting from and on behalf of the entire Unix RoundTable we thank you. The NeXT users continue to lead the way in the library. If you want to see your platform enjoy the same growth and recognition you are going to have to follow their example. -- Lead Sysop Notes Andrew Finkenstadt ---------------- Chief Sysop As this article is being written I have just thought over the past few months of our expanded activity in the Unix RoundTable. Our real time conferences are about to expand - you will be able to find persons sharing the Unix interest more frequently. The software libraries have burgeoned with an influx of new material from the archives: NeXT specific files are growing thanks to the work of Eric Tremblay, Frank Cupo, and others. A free version of Unix called LINUX has been uploaded by member Mike Nolan. We've expanded our Bulletin Board by 5 additional categories to include Sun, NeXT, the Coherent Operating System, Sequent, and a new "let's relax" category for the lighter side of Unix. And more is on the way. If you have any suggestions for areas that we should cover to make your participation in the Unix RoundTable more pleasant, please don't be bashful. We'd love to hear from you, just send some mail to the GE Mail address UNIX$ or directly to any of the Sysops: ANDY Andrew Finkenstadt GARS Gary Smith LRARK Rick Mobley DELPHI Brian Riley and our newest SysOp Mike Nolan Thank you for your patronage. -Andy Unix RoundTable Chief Sysop Upload Contest Winners for March (ANDY) -------------------------------- The Unix RoundTable is proud to announce the winner(s) of the February 1992 Upload Contest. To: E.TREMBLAY2 Eric Tremblay Sub: Upload Contest :) Eric, Congratulations! You have won both sides of our upload contest again: both for number of files and quantity/bytes of files. Let me know when you want your next two free days. :grrin: -Andy Sub: Upload Contest Data & Winner UPLOADER COUNT(0) SUM(FILE_SIZE) ------------ ---------- -------------- ANDY 3 595072 DELPHI 1 16768 E.TREMBLAY2 30 4067072 F.CUPO 10 1476352 GARS 126 5908992 <-- disqualified, SysOp I.SHAPIRO3 5 2087424 J.MURPHY3 1 25216 M.NOLAN 24 3235072 System Handy Hint: Do you have a boot diskette/tape (GARS) ----------------- Don't be too quick to answer that in the affirmative if your boot is the standard boot diskette shipped with the system. This is a "bare bones" version only, and does not contain spaecial device files - like the one for your 'backup' tape drive. If your backup boot is the standard boot diskette you are looking at a very long rebuild session, and some systems make it even more tedious by requiring you to re-enter the serial number of your software. Presume for a moment you can live with all this aggrivation, then ask yourself when was the last time you verified the boot diskette was readable. Do yourself a favor and create your own boot diskette that contains the latest level of your Unix kernel and that driver for the all those system and application files. WHO short bios --- This issue we get a closer look at a couple of our new on-line support gurus. These are the individuals who have graciously volunteered to man the special platform specific areas. Peter Wargo (PSYCLOPS) Sun wizzard I began my road down computer nerddom when I transferred from RPI (Electrical Engineering) to Clarkson University (Technical Communications). While I was doing this, that and the other thing, I strayed from my Macintosh to MS-DOS - lured, it seemed, by the cryptic command prompt. Not satisfied with a C:\> prompt, I was lured into UNIX when the University PR department (where I worked) was privy to a gift of 15 Sun 2/120's. A master Unix Guru, Rob Logan, taught me how to turn 15 piles of junk into 7 piles of working junk, and the rest is history. I learned, and prospered. Today I work at Enable Software, Inc. (More DOS crap) where I have my lovely SPARCstation IPC to keep me company. (Used for Interleaf) One final note: My qualification for being the "Sun God" (as such it is...) is this: I *ACTUALLY* admit to owning my own personal Sun 2/120!!! Scott Ingram (SINGRAM) Coherent wizzard Scott Ingram: Native of the Pacific Northwest, likes sailing and computers almost as much as cooking and best of all, eating. Started programming computers around 1974 on a Model 33 tty attached to an IBM 360. Spent the last 10 years playing with the hardware side of things as an electronic warfare specialist with the Navy and Coast Guard: Breaking things at long distance is my specialty. Became interested in multitasking and Unix like environments when I got frustrated with the ease that you can crash DOS when it has unusual hardware to contend with. (Okay, I *KNOW* that it probably was't a good idea to solder that Triumph Standard 2 liter with the twin Zenith sidedraft carburetors on, but it really did look like the reactor plant interface should have worked.) In looking for an economical alternative to current implementations of Unix, came across Coherent, which is really fun to have at the house, in spite of the fact that I really don't care for the C programming language at all. (My military experience with Ada has left me with a strong predilection for Ada and Modula-2.) Now maybe that leftover Pontiac that my brother has-ever seen a 386SX do 100 knots in 2 foot seas? FAST and NASTY, DOWN and DIRTY: quick fix scripts that do something -------------------------------- Subject: Four line 'today' program Subject: Re: Show day of month shell. Message-ID: <5610@public.BTR.COM> Date: 16 Feb 92 08:30:59 GMT References: <qPs1FB1w164w@tsf.UUCP> In article <qPs1FB1w164w@tsf.UUCP> gnr@tsf.UUCP (GodNet Raider) writes: > The following file will print a calender on the screen with the >present day hi-lighted on ansi terms (I know a 'c' program would be faster >but just wanted to play with shell scripts). >[...] Lawdy. I've enclosed a 4-liner (not counting the comments) considerably more portable due to use of "tput" (so as to work with any terminal with which one has identified to one's system). The comments are mine regarding fixing a bug in the original version of the script as found in "Tricks of the UNIX Masters". Thad Floryan [ thad@btr.com (OR) {decwrl, mips, fernwood}!btr!thad ] -------------------- begin enclosure # @(#) today v1.1 Calendar with today highlighted; based on TUM pg.167 # # output of `date` is: Thu Dec 1 05:47:14 PST 1988 # {1} {2} {3} {4} {5} {6} # # the original code in TUM (Tricks of the Unix Masters) was flawed in that # a day of 1 (for example) would cause substitution in all numbers beginning # with a 1. The modified code (below) prepends and appends a space to each # line to permit an exact match in the regexp search for the day value. # # If YOUR version of "cal" requires the month and year to produce the single # month calender, then alter the last line to start thusly: # # cal ${2} ${6} | ... # # If your version of "cal" requires a numeric month number, then some other # technique will be required (to convert, say, "Dec" to "12"). set `date` RVR=`tput smso` NORM=`tput rmso` cal | sed -e "s/^/ /" -e "s/$/ /" -e "s/ ${3} /${RVR} ${3} ${NORM}/" #------------------- end enclosure TUTORIALS: ========= bin/sh part 2 Rick Mobley (LRARK) ------ This is the second part of this series. In the first part we covered most of the basics. If you missed, I suggest you go back and review them before continuing to press forward. The basics are important and will help you discover the heart of this and any other sequence. So let go! As each command is executed the following occurs. First the shell has to determine whether the command is built-in, a defined function or an external executable file. Other than additional processes, which are spawned as needed, commands are executed in a similar manner. It is important to note here that the order of execution is as follows: Built-in commands are executed first, if found, before searching elsewhere. Second would be a defined function that you have included as a part of your script. Third would be an external executable file. This executable file can be a compiled 'C' program, or even another script that has the --x (executable) bit set. See 'chmod' for more information on this. The following should hold true for most systems, but I'm sure there will be exceptions. Normal searches for externals will be /bin, /usr/bin, /etc and finally in your current directory. The exception here will be if you append the path when you invoke the script, ie /usr/rick/makeit. This will cause the script to only search /usr/rick for its externals. If you put your program in the background (terminated with a &) signals such as INTERRUPT and QUIT will be ignored. You will have to find the process-id by running 'ps' and issuing a 'kill ##', where ## is the id of our process, unless it has terminated without intervention. See 'trap' for more information on signals for the shells. Command parameters are often file names. Here are a list of special pattern-matching parameters that you will find useful. * Matches any string, including the null string. ? Matches any one character. [...] Matches any of the characters enclosed in square brackets. [!...] Matches any character other than those enclosed in brackets. I find these useful, even from a command line. For instance, if I wish to use cpio to archive my directory to tape. I can issue a command like: find . -print | cpio -ocvB >/dev/tape Or if I wish to view several files that have common names, I can issue: less *.txt or less arc* or less plug[1,2,3].doc or even less perl.patch[0-9] Be careful when you expand filenames as destructive gremlins lie waiting for you to mess up. Can you imagine what 'rm *' might do! Please don't try this at home, alone and without good reliable backups. There, I've warned you now! We can assign values or strings to variables to make our program more robust. Here we need to learn something about variable substitution. For instance: stars=***** assigns 5 asterisks to a variable called stars, and referred to as $stars in our scripts. However, if we put single quotes around our variable $stars, substitution will not be performed. Try: echo '$stars' and see if you don't agree. Substitution takes place right to left sometimes surprising you with unwanted results if you embed variables in other variables. Parameters are passed from shell to shell by using the built-in 'export' command. To see what your shell currently knows about, enter 'export' at the command line. To get a list of name-value pairs in the current environment, enter 'env' at the command line. To see all assigned variables, enter 'set' at the command line. These variables can be useful, and are often times used to hold information that will be processed later in the script. Some variables you may see that the shell uses frequently is HOME, MAIL, PATH, PS1, PS2 and IFS. Most of these are set in your .profile each time you log in. I sometimes make use of these variables while reading usenet news. I can be deep down in my directory tree and save a file to my HOME directory by issuing a command like: mv reset.c $HOME or cp makeit $HOME/bin/makeit_new The first command moves a file to my HOME directory, otherwise /usr1/rick whereas, the second command copies a file to my bin directory and renames it as well, otherwise /usr1/rick/bin/makeit_new. Lets end this issue with some special variables. There are some useful variables that are only settable by the shell. These are: $# The number of positional parameters passed to the shell, not counting the name of the shell procedure itself. $? The exit value of the last command executed. (Discussed earlier) $$ The process number of the current process. $! The process number of the last process run in the background. $- A string consisting of the names of the execution flags currently set in the shell. You can use these to get creative. If you wanted to create a temporary file to hold some garbage. You could set a variable with a command such as: temp=$HOME/temp/$$ Then use it to store your files: ls >$temp Then remove your temp file when your work is completed: rm $temp In the next issue I will continue with command substitution and begin to experiment with some flow control commands. From the command line you can cut down on your work and achieve some extraordinary results. Ricky Mobley [lrark] Little Rock, AR vi - part 2, basic edits (GARS) Gary Smith == ------ ----------- A tutorial on the Unix visual text editor from the GEnie Unix RoundTable -- abstract -- Part 1 provided an introduction to vi and gave a quick start overview so neophytes could use the power of vi() immediately, even if limited to basic edit functions. In Part 2 (this session) we are going to cleanup our test file using the tools introduced in Part 1, and elaborate on shortcuts and develope work strategies that will unfold more of the power hidden within vi. I am going to make an observation now, that at first seems absurd; but as we progress in our understanding of vi I hope you will come to realize the full significance of this statement. "It is entirely possible, sometimes even desirable, to complete a full Unix session and never leave vi." You can run commands, call processes and manage your entire Unix environment from within vi. Why would you ever want to do such a thing? Consider editing a process, interactively testing and debugging, and making corrections on the fly... That might be a reason. -- recap -- - vi is modal. There two operating modes: 'text entry' and 'command' mode. The _normal_ mode for vi is the command mode. This is the initial state. Text entry mode is accessed from the command mode when you wish to type in, insert or replace existing text. To exit the text entry mode you press the ESCape key. - cursor control (from the command mode) If your arrow keys do not move the cursor as expected and your terminal is correctly identified _or_ if you just prefer using generic keys these are the letter keys associated with cursor movement. h - move the cursor left one character (so will backspace) j - move the cursor down one line k - move the cursor up one line l - move the cursor right one character (so will spacebar) To move the cursor more than one position preceed the cursor key (letter or arrow) with the number of positions you wish to move. ie: 3j will jump the cursor down three lines. 2k will jump the cursor up two lines vi also provides you with some handy one keystroke cursor jumps. 0 (zero) - will jump to the beginning of the current line $ - will jump to the end of the current line G - will jump to the first character last line of the file - adding text We have six basic ways to insert text, all of them mnemonic. i - (i)nsert text before the cursor I - (I)nsert text at the beginning of the current line a - (a)ppend text after the cursor A - (A)ppend text at the end of the current line o - (o)pen a line one line below the current line O - (O)pen a line one line above the current line -- first edit session -- If you did all the exercises called for in Part 1, you have a file (we named test) that looks like this: This is a test file to be used for procticing various commands using the vi editer. As we insert more text we insert more text we also further complicat the file and add to possibilities for edit practice. Later we will expand beyond one screen to test various functions such as search and scrolling. This is one more line of text to mess with added with the o command. ~ ~ ~ ~ "test" [New file] Since you saved this file at the end of Part 1, it's time for us to call it, by typing: vi test The file will scroll onto the screen just as we left it with one exception. The status line now says: "test" 12 lines, 464 characters Don't worry if you have a slightly different line or character count. Spaces and blanks are counted, as well as visible characters and lines. What you should be concerned with is the body of the file that we will be editing. Notice also that your cursor is at the top of the file. This is quite the opposite from ex(), which opens a file from the bottom. Remember, vi and ex are completely inter-related. vi is actually the (vi)sual command of ex. We will be using ex commands, so get accustomed to my references to it. If you want to confirm how ex opens a file, close test now by typing a colon, then at the colon prompt type :q! <cr> (<cr> implies Carriage Return) Now open the file using ex, by typing ex test. You will get the same status line as before, with no visual text and a colon prompt. At the colon prompt type :vi <cr> and notice you will get your screen of text, with tildes marking empty (as opposed to blank) lines, but your cursor is at the bottom of the file. You can place the cursor back at the top by typing 1G <cr>. This tells vi to move the cursor to line number x. 3G = line 3, 15G = line 15. Also, remember that just G with no line number defaults to the end of file? Cursor over to the misspelled procticing, using the arrow key or letter l. Stop when the curor is positioned on the 'o'. Type r then a. You have just discovered another mnemonic command. r is used (in command mode to replace a character). Next let's jump to line 4, where we repeated the phrase 'we insert more text'. You can get there by individual cursor movement, or you can type 4G to go to line 4, and cursor over. You can also cursor straight down using the down arrow (or letter j). There is no absolutely right way to get to the point you wish to edit. Use them all. Soon you will discover certain methods are quicker in certain circumstances. However you get ther, once you are positioned on top of one of the w's in one of the duplicate we's you can type x to delete any character under the cursor or X for the character before the cursor. You can thus delete each mistyped (or in this case, extra charcater). You could do that. You could also wipe them out a word at a time by typing dw (delete word - another nice mnenomic). This process got rid of the extra phrase, but now we have a ragged, uneven line. Unix provides tools for formatting text, but let's see what we can do using just basic vi tools. Position your cursor at the end of line 4, by typing 4G to go to line 4, followed by $ to move the cursor to end of the line. Type a (insert after), followed by typing in 'further complicate the' Hit escape to get out of the insert mode and back into command mode. Move your cursor to the start of line five and delete the first three words using dw (delete word). Jump to the end of line 5 (using $) and type a (insert after) and insert 'for edit practice'. Hit escape to return to command mode. Position your cursor at the start or end of line 6 (or anywhere in line 6), and type dd. Bingo! You just erased the entire line. What if you were on the wrong line - or screwed up ANY of the session. If you caught your mistake as you made it just type u to undo the last command. Later we will discover you can atone for many sins, but for the moment lets stick with fixing one (the last) oops! at a time. Your test file should now look like this: This is a test file to be used for practicing various commands using the vi editer. As we insert more text we also further complicate the file and add to possibilities Later we will expand beyond one screen to test various functions such as search and scrolling. This is one more line of text to mess with added with the o command. ~ ~ ~ ~ Save test, using either ZZ or :wq! The closing status will be something like:"test" 11 lines, 420 characters. Again, don't worry about exact character count. One reason is I spaced my test file over to center it in this article. Next session we are going to learn more about c, d, and a new friend y. We are going to use y, along with p and start doing some serious text movement. We are finally going to leave the basic stage and reach inside some of vi's hidden goodies. We are going to have some fun. We are finally going to go inside vi() and learn some tricks that give vi power beyond mere editing. __ _ Gary Smith * ... uunet!ddi1!lrark!glsrk!gars * / _' _ _ (_' P. O. Drawer 7680 * nuucp%ddi1@uunet.UU.NET * /__/ (_|_/ '._) Little Rock,AR 72217 * GEnie Forth RT & Unix RT SysOp * --------------- - U. S. A. - * ph:501-227-7817,fax:501-228-9374 * 0800 - 1700 GMT -6 --------------- REMINDER - This newsletter is being sent to you 'by request'. If you do not wish to keep receiving it, e-mail a stop notice to GARS. On the other hand, we would very much appreciate it if you would pass the word that we do distribute this item near the tenth (10th) of the month of issue to any- one on GEnie who requests it, and will gladly add any name that is requested via the same route... e-mail to GARS. P L E A S E also remember contributions are most welcome. Please e-mail items and/or suggestions to GARS. (EOF) Trademark and Copyright notices: Unix is a Trademark of UNIX System Laboratories, Inc.; GEnie, LiveWire, and RoundTable are Trademarks of General Electric Information Services Company; Xenix and ms-dos are Trademarks of Microsoft Corporation; NeXT and NeXTstep are Trademarks of NeXT Computer Systems, Inc., Coherent is a Trademark of Mark Williams Company, Sun is a Trademark of Sun Microsystems, Inc, Sequent is a Trademark of Sequent Computer Systems, Inc. The contents of this newsletter are copyright (c) 1992 and may be copied whole or in part only if original credit is included. The GEnie UNIX RoundTable is not affiliated with AT&T or UNIX System Laboratories, Inc.